The invention relates to a method for handling conversational transactions in a distributed processing environment and specifically to such a method suited for use in real time fault tolerant transaction processing system employed in a service control point.
A service control point ("SCP") is a fault tolerant transaction processing system that controls routing of telephone calls, within the telephone network, that require special handling, such as 800 and calling ("credit") card calls. In particular, whenever a telephone subscriber dials such a call, the call is first routed to an equal access switch, located either at a local office or elsewhere, which has service switching point capability (such a switch will hereinafter be referred to as an "SSP"). Primarily, the SSP processes calls that require remote data base translation. Now, whenever the SSP recognizes a call as one that requires special handling, the SSP suspends normal call processing, launches a message over a common channel signalling ("CCS") network to an SCP to determine how the call is to be routed, and finally upon receipt of a response message from the SCP, routes the call in a manner specified by the response message.
Specifically, whenever a subscriber places a call to an 800 number, the local switch routes the call to an SSP. The SSP fabricates a query in the form of a packet. This packet contains the 800 called number and a request for a destination routing number associated with the 800 number and, additionally, identification of a particular long distance (inter-exchange) carrier over which the call is to be routed. This packet is then routed over a common channel signalling line in a CCS network to a particular one of several geographically separated signalling transfer points (STPs). Specifically, the CCS network typically consists of a multi-level hierarchy of STPs, wherein each STP is primarily a packet switch. The first STP to receive the packet, i.e. the "originating" STP, then routes the packet, over an available link to an SCP for processing or, via a specified link, to another STP for eventual routing to an SCP.
The SCP itself is a fault tolerant transaction processing system that contains various databases that collectively provide desired call routing information. These databases contain a "customer record" which for 800 calls to a particular customer specifies how each such call is to be routed. For example, this record frequently contains one or more destination routing numbers associated with a particular 800 number and specifies the manner in which one of these destination routing numbers is to be selected, e.g. in accordance with the time of day, day of month, originating numbering plan area of the caller or other pre-defined method. Each transaction processed by an SCP for 800 service typically involves receipt of a packet followed by generation of a corresponding response. In particular, whenever a query is received, via an incoming packet, the SCP performs associated database access operations to obtain a necessary destination routing number and an inter-exchange carrier identification for the corresponding 800 call. The resulting information is then transmitted, as a packet, over the CCS network by the SCP, and via one or more STPs, back to an "originating" SSP which generated the corresponding query. Once a packet containing the destination routing number and inter-exchange carrier selection is received, the originating SSP appropriately routes the 800 call to the destination routing number.
Various architectures can be used to implement an SCP. One such architecture is disclosed in detail in Boese et al United States patent application, "A REAL-TIME FAULT TOLERANT TRANSACTION PROCESSING SYSTEM" , filed Nov. 25, 1987, Serial Number 07/125,463 now abandoned and succeeded by continuation application filed Dec. 12, 1989, Ser. No. 07/453,042 both of which are currently owned by the present assignee and is disclosed to a much lesser extent in J. O. Boese et al, "Service control point--Database for 800 Service", Conference Record of Globecon '86: IEEE Global Telecommunications Conference December 1-4, 1986 Houston, Tex. Vol. 3, December 1986, pages 1316-1319. This architecture, hereinafter referred to as the replicated front end--back end architecture, is a network based communication system that employs: (a) a layered communication protocol that adaptively distributes packets on an approximately equal basis over multiple active physical links that connect two points (nodes) within the network, such as, for example, an SCP and an STP, and (b) a pair of non-fault tolerant front end (FE) and back end (BE) processors that is connected within the SCP to each physical link for handling the processing of packets appearing on that link. Each FE processor is connected to a corresponding link in a link set and is, also, connected to an associated BE processor. All the BE processors are connected through an appropriate coupling device, such as a star coupler, to a shared disk farm in order to provide access to files stored therein. The protocol, hereinafter referred to as signalling system 7 (SS7), is the ANSI (American National Standards Institute) implementation, as recommended by the ANSI T1X1.1 working group of the signalling system 7 standard that has been initially promulgated by CCITT. All the FE and BE processors are loosely coupled together, through various local area networks, for purposes of processor synchronization and re-assignment.
Each FE processor handles the SS7 protocol which includes framing, synchronization, error checking and correction, and other associated communication tasks. Its corresponding BE processor provides database access operations to support query processing. One of the BE processors within the SCP executes various software procedures to co-ordinate the operation of all the FE and BE processors therein so that individual processors within the SCP and/or any application software executing on any of the BE processors can be gracefully brought into or taken out of service.
Now, in the event any physical link in a link set or either a FE or BE processor connected thereto fails, then that link is declared to be out of service. When this occurs, the STP that is connected to that link set, through processing of the SS7 protocol, merely re-assigns all subsequently occurring packets among all the remaining active links in the set until such time as the fault is cleared. By virtue of link re-assignment, there is no need to connect a fault tolerant processor to each physical link. As such, a number of loosely coupled FE-BE processor pairs can be substituted within an SCP for a number of fault tolerant processors. Now, by eliminating the need to use fault tolerant processors, advantageously the replicated FE-BE architecture substantially reduces the complexity and cost of an SCP.
The replicated FE-BE architecture provides excellent fault tolerant performance for simple "Query--Response" type transactions. Such a transaction is typified by one, as discussed above, in which a query, such as an 800 call query, is sent out by an SSP to an SCP and a needed response, i.e. the destination routing information, is furnished through a single database access and then sent by the SCP back to the SSP. Unfortunately, not all transactions that require SCP processing are quite so simple.
In particular, in certain enhanced network services, such as those needed to implement a private virtual network (PVN), the transactions are much more complex than simple "Query--Response" transactions. Specifically, these services often require a caller to enter information, in addition to the called number, on an interactive basis before the SCP can fully process the call. In particular, for such a service, the caller generally dials an appropriate telephone number to gain access to the service. Once this occurs, the SSP associated with this caller routes a request to the SCP that handles this service. The SCP performs a database access into a customer record to determine the next piece of needed information, e.g. a personal identification number (PIN) and authorization code, that has to be obtained from the caller. Once this occurs, the SCP requests this piece of additional information by in effect questioning the caller. In particular, the SCP inserts an appropriate op code within a transaction capability application part (TCAP) message, and then transmits this message as an SS7 packet via the CCS network back to the SSP. In response to this op code, the SSP synthesizes a pre-defined voice message to prompt the caller to enter the desired piece of additional information. Once the caller provides an answer, it is transmitted as a TCAP message within another SS7 packet by the SSP back to the SCP that requested it. In response to the answer, the SCP then re-accesses the customer record in order to determine the next piece of information it needs from the caller, and so on. Inasmuch as the nature of each additional piece of information often varies in response to the previous answer, the question and answer session occurring between the caller and the SCP is carried out on an interactive basis. Each question and answer session, henceforth referred to as a conversation with each TCAP message that carries part of the conversation being referred to as a conversational message, continues until the SCP has collected enough information from the caller via the SSP, as defined by the customer record, to fully determine how the call is to be routed. Once this occurs, the SCP sends its response containing destination routing information back to the SSP which, in turn, routes the call accordingly. At this point the SCP has fully processed the transaction. As such, a conversation based transaction can be viewed as "Query--Conversation--. . . --Conversation--Response".
Unfortunately, the replicated FE-BE architecture is not suited for readily processing conversational transactions. As noted, incoming packets to an SCP are distributed by the SS7 protocol on an approximately even basis among the active physical links in a link set connected to an SCP and from there to corresponding FE-BE processor pairs located within the SCP. A typical conversational transaction typically involves a series of incoming packets to an SCP. As a result of packet distribution occurring over a link set, individual packets that form the conversational transaction will probably be scattered among all the FE processors in the SCP that are associated with active links in that set. Consequently, if conversational transactions were to be processed in the replicated FE-BE architecture, then the particular ("starting") BE processor that starts processing the transaction and generates the first conversational message will generally not be the BE processor that will process the answer to that conversation or all the remaining conversational messages in the transaction. Inasmuch as the state ("context") of the transaction will be stored in a database associated with the starting BE processor, none of the other BE processors will be able to associate a conversational message with this transaction and appropriately continue processing this transaction. Consequently, once a packet that forms this transaction reaches any BE processor other than the starting BE processor, the former BE processor will likely discard the transaction. As such, the SCP will not provide the caller with a desired enhanced service. The same result follows if a BE processor fails and the transaction must be taken over by another BE processor.
Hence, an SCP in its present form and based on the replicated FE-BE architecture is not suited to handling conversational transactions. For that reason, such an SCP would be generally unable to provide certain enhanced network services, such as PVN, that require an interactive conversation with a caller.
Thus, a need exists in the art for a method for handling conversational transactions in a distributed processing environment, particularly one suited for use in real time fault tolerant transaction processing system employed in an SCP. Use of such a method will advantageously enable an SCP that utilizes a replicated FE-BE architecture to provide enhanced network services that require the collection of successive pieces of information on an interactive basis from a caller.